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TECHNICAL FIELD 
[0001] The subject matter relates generally to instant messaging and more 

specifically to presence-based seamless messaging. 

BACKGROUND 

[0002] Expansion of network infrastructures for computers and telephones 

has increased opportunities for personal connectivity. Email, voice mail, instant 
messaging (IM), short messaging service (SMS), wireless telephony, paging, 
facsimile (fax), and voice-over-IP (VoIP), to name a few, are communications 
"media" that offer a person numerous avenues for contacting and conversing with 
another. 

[0003] Message format can be distinguished from transport mechanisms for 

sending a message and this distinction is accentuated by transposition engines that 
can turn text content into speech and vice versa. A message can be transported to a 
recipient by any number of communications media. Thus, message format does 
not automatically specify or limit the message to a particular transport medium. 
[0004] Often, a person composing and preparing to send a message via one 

communications medium selects another more efficacious communications 
medium if the process of switching between media is easy and the sender knows 
for certain that the recipient is "present" to the new medium. For example, a 
sender might place a telephone call instead of spending extra time composing an 
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email message, if the sender somehow knows that the recipient is near the phone. 
Conversely, a sender writing an email might have resources at hand to ascertain 
that an intended "buddy" recipient is online for exchange of real-time instant 
messaging instead of email, but may not want to go to the trouble of finding the 
system's list of buddies, ascertaining whether the intended buddy recipient is 
online, leaving the email application, opening the instant messaging application, 
and initiating an instant messaging conversation. The effort of manually 
performing these multiple steps of changing communications media, including 
waiting for a computing device to load software, tends to break the sender's 
workflow momentum, and may be avoided as not worth the effort. 
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SUMMARY 

[0005] The subject matter described herein includes systems and methods 

for performing presence-based seamless messaging, which allows one type of 
communications medium, such as email, to smoothly become another type of 
communications medium, such as instant messaging (IM). In one implementation, 
a messaging system has the ability to seamlessly transition between 
communications media, which facilitates dispatch of messages via the most 
efficient real-time communications medium available to the recipient at the 
moment the message is to be sent. The messaging system senses the presence of a 
potential message recipient who can be reached via a communications medium that 
is not currently being used by a sender composing a message. The system can 
either transition automatically to an environment for composing and sending the 
message using the presence-based communications medium or can offer the sender 
a menu of presence-based communications options that includes switching to the 
presence-based communication medium. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
[0006] Fig. 1 is a block diagram of an exemplary media transition system for 
presence-based messaging. 

[0007] Fig. 2 is a block diagram of an exemplary media transition engine. 
[0008] Fig. 3 is a graphic representation of an exemplary dynamic menu toolbar 
for presence-based messaging. 

[0009] Fig. 4 is a graphic representation of an exemplary seamless transition 
from an email environment to a presence-based communications medium. 
[00010] Fig. 5 is a graphic representation of an exemplary dynamic menu for 
presence-based messaging. 

[00011] Fig. 6 is a graphic representation of another exemplary dynamic menu 
for presence-based messaging. 

[00012] Fig. 7 is a graphic representation of an exemplary dynamic menu and 
associated relational database logic for presence-based messaging to multiple 
message recipients. 

[00013] Fig. 8 is a flow diagram of an exemplary method of presence-based 
seamless messaging. 
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DETAILED DESCRIPTION 

Overview 

[00014] The subject matter described herein includes systems and methods 
for performing presence-based seamless messaging, which allows one type of 
communications medium, such as email, to smoothly become another type of 
communications medium, such as instant messaging (IM). The ability to 
seamlessly transition between communications media facilitates dispatch of 
messages via the most efficient real-time communications medium available to the 
recipient at the moment the message is to be sent. "Smooth" and "seamless" as 
used herein mean successful transitioning between communications media with 
reduced delay (and/or reduced steps to be manually performed by a user) compared 
with conventional manual methods of switching between communications 
programs on a computing device. The terms "smooth" and "seamless" are also 
used herein to mean that an exemplary system can change user interfaces for 
messaging and message composition environments with a logical flow, without 
error, and without jarring abruptness from one communications medium to another. 
The seamless transitioning between communications media described herein may 
include completely automatic transitioning or "one-click" transitioning effected by 
actuating only one control button or icon. 

[00015] In conventional daily life, the manual selection of a particular 
communications medium is often based on perceived or supposed availability of a 
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potential human recipient. If a sender knows with some reliability that an intended 
recipient is near a phone, then the sender will likely use the phone medium instead 
of writing a letter or sending an email. The availability of another person for real- 
time communication is known herein as "presence." A person who is available for 
real-time communication is "present" while a person who is not available for such 
real-time communication is not present. "Modified presence" refers to a person 
who is present but has specified that contact be made conditionally only through 
limited avenues. For example, if the potential recipient is in a meeting, then 
perhaps only non-audible avenues of initiating communication are desirable. 

Exemplary System 100 
[00016] Fig. 1 provides an overview of an exemplary presence-based 
seamless messaging system 100. A message sender 102 initiates a message to be 
transferred to one or more potential recipients 104. The recipient(s) 104 advertise 
their presence with respect to one or more communications media as feedback to 
an exemplary media transition engine 106. For example, a first recipient may be 
online, i.e., present for real-time IM exchange. A second recipient, however, may 
be offline but present to short messaging service (SMS) through his cell phone. In 
other words, different recipients 104 can be simultaneously present to a sender 
102, but across different communications media. 
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[00017] In one implementation of the seamless messaging system 100, a 

si 

sender 102 can select automatic transitioning ("auto-transitioning") prior to 
messages being sent. The seamless messaging system 100 then detects a new 
presence of the intended message recipient relative to a particular communications 
medium and automatically changes the sender's user interface (UI), as needed, to 
suit the communications medium that the recipient is present to. Thus, the system 
100 can transition the sender's UI seamlessly from one type of communications 
medium to another. In the background, an exemplary media transition engine 106 
underlies the seamless UI transitions and also seamlessly transitions between 
application programs enabling the various communications media. For example, 
an email UI and its underlying program can become an instant messaging UI and 
program in response to the intended recipient of the email becoming present online 
for IM, without the user having to perform manual steps to switch between email 
and IM. Conversely, an IM chat window might seamlessly become an email 
composition pane as connection-presence with the recipient is severed. 
[00018] If the user has not selected auto-transitioning between 
communications media, then an exemplary seamless messaging system 100 
presents the user with a choice of whether to change media. The presentation of a 
choice may be in the form of a dynamic menu of presence-based messaging 
options. The dynamic menu may grow or shrink depending on potential recipients' 
presence to various media. From the menu, the sender 102 can select a 
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communications medium over which the recipient 104 is present. Of course, 
options for message transfer using media for which the recipient is not present, can 
also be included to create a dynamic menu that is not totally presence-based, i.e., 
the sender 102 may be given options to use media for which the recipient is not 
present for "instant" communication. 

Exemplary Media Transition Engine 106 
[00019] Fig. 2 shows the exemplary media transition engine (MTE) 106 of 
Fig. 1 in greater detail. The exemplary MTE 106 is communicatively coupled as 
illustrated and may be implemented as software, as hardware, or as a combination 
of both. The illustrated exemplary MTE 106 may contain address book database(s) 
200 useful for storing parameters by which the presence of contacts listed in the 
address book database(s) 200 can be determined for various media. For example, 
the address book database(s) 200 can be used to determine if a particular recipient 
is on a "buddy" list to be checked for online presence. It should be noted that an 
address book database 200 can be information stored locally on a user's computing 
device; can be a local area network (LAN) service (e.g., a WINDOWS® ACTIVE 
DIRECTORY®); can be a wide area network (WAN) service; or can be another 
information source stored inside or outside an exemplary MTE 106. 
[00020] For a given recipient 104 listed in an address book database 200, a 
media detector 202 may establish which communications media are periodically 
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available to a recipient 104. For example, a given recipient 104 in the address 
book database(s) 200 may have entries indicating that the recipient 104 has email 
access but not IM access. In some cases, a media detector 202 or subcomponent 
may be able to detect communications media periodically available to a potential 
recipient 104 by attempting to open the communications medium; by pinging; etc. 
[00021] A presence detector 204 determines if a recipient 104 is present for 
real-time communication on one of the communications media found by the media 
detector 202. In one implementation, a presence detector 204 accomplishes 
presence detection via APIs published by each application program associated with 
a communications medium. For example, an IM application that knows when a 
recipient 104 is online can make this presence known to other communications 
programs. 

[00022] A media integrator 206 allows or facilitates sharing of information 
between communications programs underlying various media, for example, by 
acting as a common translator for and interpreter of disparate APIs, in the event 
that two communications programs are not custom designed to expose relevant 
APIs to each other for purposes for advertising a recipient's presence. In this type 
of implementation, the media integrator 206 may manage APIs between various 
communications programs so that each communications program can advertise a 
recipient's presence. 
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[00023] Alternatively, instead of trying to weave together discrete 
communications programs, an exemplary MTE 106 may use an integrated 
communications program that administers multiple communications media at once. 
In this case, there is no need for API coupling, translating, or interfacing because 
knowledge of presence among the various communications media is known 
internally to the integrated program that runs them all. If an integrated 
communications program is not used, then an exemplary media integrator 206 may 
have a "simultaneous programs" engine 208 to invoke multiple communications 
programs contemporaneously in order to achieve smooth and speedy transitions 
between two communications programs as the focus of control changes from one 
to the other. The term "invoke" as used here means to initiate an application 
program for a communications medium if the application program is not running, 
or if an application program for a communications medium is already running, 
then establishing sufficient interfaces with the application program to be able to 
use the associated communications medium immediately for sending a message. 
[00024] A media integrator 206 may also include a user interface (UI) 
transition engine 210 to perform smooth transitions between the UIs generated by 
communications programs and to bring unsent message content from a prior 
message composition environment to a subsequent message composition 
environment. In some implementations, a user is prompted or offered an option 
via a dynamic menu 216 to initiate a transition from a prior communications 
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medium and UI to a subsequent medium and UI. A UI transition can be 
accomplished by different techniques. For example, an IM chat window can be 
visually generated within an email composition pane. Or, a UI transition engine 
210 may change the message composition environment associated with one type of 
medium into the composition environment for another type of medium with very 
little perceptible change to the user. Thus, a sender who has selected auto- 
transitioning between media types might experience an email composition pane 
seamlessly change into an IM chat window as a recipient comes online. 
[00025] During media transition, a content translation engine 212 may 
change existing message content into that of the new medium. In some 
implementations of the subject matter, a transition between communications media 
includes pre-populating the new medium, e.g., the message composition area of the 
new UI 404, with message content from the prior UI 402. In one implementation, 
a content translation engine 212 includes editing features so that a sender 102 can 
select which text to carryover from one medium to the next. In the case of an 
email-to-IM transition, the content translation engine 212 may use the subject line 
of the email as part of a subject line of the IM or as one of the first lines of IM 
chat. The content translation engine 212 may also recruit content from the body of 
an email for the subsequent communications medium. In one implementation, the 
content translation engine 212 copies a certain number of bytes of the email 
message from the prior UI 402 to paste into the new IM UI 404 as real-time chat. 
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[00026] Typically, an SMS message is limited to, e.g., 160 characters. The 
content translation engine 212 may present the user with the option of creating two 
messages from one SMS message if the user is composing a message longer than 
160 characters. Alternatively, the content translation engine 212 may offer the user 
the option of reducing the text length to fit the limit as many users pay for each 
SMS message and the choice of splitting a message into two is not always cost 
effective. 

[00027] Once the presence detector 204 determines a recipient's presence 
over one or more communications media, a menu controller 214 may post a 
dynamic menu 216 on the sender's UI of communications media choices that allow 
a message to be sent "instantly." The menu 216 is called dynamic because the 
number of menu choices grows or shrinks depending on the presence of the 
recipient 104 with respect to multiple communications media. Hence, if the 
recipient 104 goes offline during IM, the dynamic menu 216 of real-time 
communications media choices shrinks. Control logic can be programmable to 
accommodate many variations in how an exemplary MTE 106 smoothly transitions 
between communications media based on recipient presence. 
[00028] In a variation, an exemplary MTE 106 is downstream from the 
message sender 102 and is not under direct control of the message sender 102, e.g., 
the MTE 106 functions like a network device. In this case, user input is not 
solicited for selecting a real-time communications medium, but instead the 
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exemplary MTE 106 selects a communications medium over which the recipient is 
present for message transmittal and returns an indication to the sender 102 of 
which medium was used to transport the message. 

[00029] In still another variation, an exemplary MTE 106 possesses 
recipient-based media router features. In this variation, an exemplary MTE 106 
allows the potential recipient 104 to select which medium an incoming message 
will be delivered by. Thus, the dynamic menu controller 214 and dynamic menu 
216 are directed to the potential message recipient 104 instead of the message 
sender 102. The potential recipient 104 specifies the message delivery actions 
based on their presence. This creates a similar end-user experience for the 
recipient of flexible, presence-based message routing as the sender-based 
implementations discussed above, but relieves the sender 102 from having to 
possess and use software to performs the presence-based media transitions. This 
variation is especially useful for when a recipient 104 desires presence-based 
messaging but the sender 102 is not very computer savvy or has only one sending 
medium in hand. 

[00030] Fig. 3 shows a piece of received email (300 and 302) during absence 
(300) of a potential reply recipient and during presence (302) of the potential reply 
recipient. The example in Fig. 3 illustrates a case in which the potential sender 
102, i.e., a user who is about to reply to the email, has not selected auto- 
transitioning, so a presence-based seamless messaging system 100 prompts the 
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sender 102 through a dynamic menu (e.g., 216 or 216') before changing 
communications media. When the potential reply recipient is absent 300 to an 
instant communications medium, the dynamic menu 216 (in this case a changeable 
toolbar of reply options) reflects reply options that do not include instant (real- 
time) reply. When the potential reply recipient is present 302 to relevant instant 
communications media, however, then an expanded dynamic menu 216' reflects 
one or more additional instant reply options 304. Thus, a dynamic menu 216 
automatically changes to reflect presence (or lack thereof) of a potential recipient 
with respect to instant reply options. 

[00031] A menu controller 214 of an MTE 106 can automatically update a 
dynamic menu 216 to reflect current presence of potential recipients 104. In one 
implementation, the MTE 106 includes client-side code that is added to a web- 
based communications client so that presence of potential recipients 104 can be 
updated in real-time. When a potential recipient's presence changes, the menu 
controller 214 may visually accentuate changing control items by highlighting, 
flashing, or otherwise drawing the user's attention to the changing menu feature. 
[00032] When a presence detector 204 senses a change in presence of a 
potential message recipient, the media integrator 206 comes into play. If discrete 
application programs are being used for each communications medium, then the 
simultaneous programs engine 208 may begin interacting with APIs exposed by an 
application program, thereby enabling for immediate use the "new" 
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communications medium to which the potential recipient 104 has just become 
present. Likewise, if the potential recipient becomes absent to a medium, then the 
simultaneous programs engine 208 may drop communication with an unneeded 
application program. In other words, the simultaneous programs engine 208 
coordinates between different applications programs underlying different 
communications media and ensures that each communications medium can be used 
immediately, i.e., that each is up and running. This enables the MTE 106 to make 
smooth and seamless transitions between media. 

[00033] Because each application program associated with the various 
communications media are immediately available, the UI transition engine 210 can 
change a message composition environment for one type of communications 
medium smoothly into a message composition environment for another type of 
communications medium. 

[00034] Fig. 4 shows a user interface (UI) transition 400 from a 
communications medium over which a potential recipient is not present to a 
communications medium over which the potential recipient is present, such as a 
transition from an email UI 402 to an IM UI 404. In one implementation (not 
illustrated in Fig. 4) the UI transition 400 occurs automatically when a potential 
recipient 104 becomes present to a communications medium that is more 
efficacious for real-time communication than the one in use. In the illustrated 
implementation, the UI transition 400 occurs as an MTE 106 responds to actuation 
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of the "instant reply" option 304 on the dynamic menu 216'. Visually, the menu 
controller 214 can use various techniques to smoothly and seamlessly transition 
between UIs. For example, the UI for the former communications medium (e.g., 
402) may visually fade out while the new UI (e.g., 404) fades in. In another 
technique, the new UI 404 is given focus of control and visually placed as a pane 
on top of the pane for the prior UI 402. In yet another implementation, the prior 
UI 402 becomes the new UI 404, that is, the humanly perceived visual changes 
during UI transition 400 are minimal. 

[00035] In some implementations of the subject matter, a smooth and 
seamless UI transition 400 between communications media includes pre- 
populating the new UI 404 with message content from the prior UI 402. In the 
case of a smooth email-to-IM transition, the subject line of the email may be 
recruited as at least part of the subject line of the IM or as one of the first lines of 
IM chat. The body of the email may also be recruited as message content for the 
subsequent communications medium. In one implementation, a certain number of 
bytes of the email message is copied from the prior UI 402 and pasted into the new 
IM UI 404 as real-time chat. In another implementation, the sender 102 can select 
(e.g., highlight) which text to carryover from one medium to the next. Conversely, 
if an IM client drops offline, a certain number of lines of chat from the IM session 
may be used to pre-populate a default email backup. 
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[00036] By allowing a user to select which text to carryover from one 
medium to the next a content translation engine 212 (or another component of a 
media transition engine 106) accomplishes the important feature of context 
preservation. The ability for a user to copy content from one medium to another 
not only preserves the context of an exchange but also saves time for the sender 
102 in composing the new message and for the recipient 104 in understanding the 
communication. 

[00037] The ability to copy text between media and preserve context from 
one medium to the next eases communication and adds an important feature for 
bridging communication styles between two media. For example, email messages 
tend to discuss multiple thoughts in an organized fashion. Instant messages, 
however, tend to be quick discussions about a single thought. An exemplary MTE 
106 facilitates communication between the two media by allowing a user to select 
a discrete point or block of text from an email message and use it as a basis of the 
"single-thought" IM medium. Thus, the user selects a block of text, then chooses 
to reply with an IM option, and the selected block of text is automatically pre- 
populated into the IM message window. This is an improvement over simply 
copying the entire email, which may be too long or complicated, or simply not 
copying any of the substance of the email, which then requires the user to retype 
the text in order to reestablish the context of the message. 
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[00038] Fig. 5 shows an exemplary dynamic menu 216 that includes an 
"instant reply using. . option 500 and a pull-down list 502 of media options under 
the "instant reply using..." option 500. The pull-down list 502 may be accessible, 
e.g., by actuating an associated mini-button 504. The number of options on the 
pull-down list 502 is dynamic and can be updated to reflect the presence or 
absence of a potential recipient 104 with respect to various instant media. In the 
illustrated example pull-down list 502, a potential recipient is currently present 
over IM, SMS, and wireless phone media, as determined by the presence detector 
204. The sender 102 may select which medium to use. In some implementations, 
a media integrator 206 may include text-to-speech and speech-to-text transformers 
known to those in the arts of voice and text transmission. This can enable an MTE 
106 to seamlessly send a text message as voice, or vice versa, without user 
intervention. 

[00039] In one implementation, a pull-down list 502 may include default 
communications media options such as email and fax that may appear in the list 
whether or not a potential recipient 104 is present to these communications media. 
Thus, an exemplary dynamic menu 216 can present a comprehensive list of media 
options between which an exemplary MTE 106 can smoothly transition, freeing 
the sender 102 from performing the transitioning steps manually and subject to 
delay while software loads. 
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[00040] Fig. 6 shows an "instant send using ..." option 600 that includes a 
pull-down list 602 accessible, e.g., by actuating a mini-button 604. Fig. 6 
illustrates that a dynamic menu 216 does not have to offer only "reply" options, but 
in some implementations can offer options for sending an original message. If the 
sending options are "instant" then the menu controller 214 may use information 
from the presence detector 204 to list only media options wherein the potential 
recipient 104 is deemed to be present over the respective medium. Wireless 
telephone and SMS can currently advertise presence of a user. Other media 
options, such as email and fax, which do not conventionally offer techniques for 
determining recipient presence instantaneously, may still be offered in a list of 
"instant send" options if recipient presence can be constructively determined. For 
example, an entry in an address book database 200 may specify that a particular 
person is to be considered constructively present at a given fax number between 
certain hours on certain days. 

[00041] "Instant send" can also be a presence-sensitive compose that resides 
in a "new message" context of an application. If the presence-based compose is 
accessed from a contact starting point (i.e., an "open a contact" option is selected; 
then a "compose a new message to contact" is selected) the instant send options 
would be dictated by both the available contact information as well as the presence 
information. In fact, accessing exemplary instant send options from the starting 
point of specific contact information provides one of the clearest and most definite 
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user interfaces to the sender 102 because the exemplary MTE 106 knows the 
identity of the recipient 104 up front and can choose from the correct and 
appropriate presence information. 

[00042] Fig. 7 shows yet another exemplary dynamic menu 216 as generated 
by an exemplary MTE 106 for a received piece of email 302. The dynamic menu 
216 includes reply, reply to all, and forward options. In addition, if a potential 
recipient 104 is present on one or more communications media, then the dynamic 
menu 216 may also include an instant reply option 304 and if multiple potential 
recipient(s) 104 are present to communications media then an "instant reply to all" 
option 700 can be included. 

[00043] In the case of multiple potential recipients 104, the control logic of 
an MTE 106 may include a relational array or database 702 that tracks current 
presence of multiple potential recipients 104 across multiple communications 
media. Hence, in a group of potential recipients 104, an MTE 106 may achieve or 
may attempt to achieve instant reply results by seamlessly sending a message or 
reply via different media depending on the presence of each recipient to the 
various media. In one implementation, email is selected as the default in case no 
presence can be determined for an intended recipient. 

[00044] In one implementation, an instant reply to all option 700 
automatically sends an IM (that is, opens a group chat) or an email depending on if 
a particular recipient in the group is online. In another implementation, an instant 
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reply to all option 700 sends an IM whether the recipient is present or not. The 
type of instant reply attempted by an MTE 106 may depend on what various 
potential recipients 104 have previously set up and given permission for. Such 
settings may be stored in an address book database 200. 

Exemplary Methods 

[00045] Fig. 8 shows an exemplary method 800 for performing presence- 
based messaging. In the flow diagram, the operations are summarized in 
individual blocks. The method 800 may be performed by hardware, software, or 
combinations of both, for example, by an exemplary MTE 106. 
[00046] At block 802, a user communicates or is planning to communicate 
via a first communications medium, such as email. In communicating or planning 
to communicate, the user typically composes a message in an editing environment 
generated by a communications program associated with the medium, in this case, 
email. Presence of the potential or intended email message recipient, who can be 
reached immediately (in real time) via a second, different communications medium 
than email (such as IM), is then detected by or from within the communications 
program driving the email environment. A presence detector 204 of an exemplary 
MTE 106 can perform the detecting of the potential recipient's real-time presence 
over the second medium, e.g., over the IM medium. An indication of a potential 
recipient's presence vis-a-vis a particular communications medium may be 
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displayed on a dynamic menu 216 posted to a UI associated with the first 
communications medium, e.g., on an email toolbar. 

[00047] At block 804, the second communications medium, e.g., IM, is 
invoked in response to detecting, at block 802, the presence of the potential 
recipient over the second communication medium. Usually, this invocation means 
that an exemplary MTE 106 either initiates an application program for the second 
communications medium, e.g., IM, or if such an application program is already 
running, then establishes sufficient interfaces with the application program for the 
second medium that the second medium can be used immediately to send the 
message, instead of, e.g., email. In other words, the MTE 106 tries to 
contemporaneously run a communications program for each communications 
medium that a potential recipient 104 is present to. 

[00048] At block 806, the sender 102 may be offered a choice to send the 
message to the recipient via the second communications medium, in this case, IM. 
A media integrator 206 of an exemplary MTE 106 facilitates a smooth and 
seamless transition between the first and second media — e.g., email and IM — 
during the offering of a choice and the message sending by maintaining 
simultaneous communication with and/or control over multiple communications 
programs. Thus, each potential communications medium to which a potential 
recipient 104 is present is maintained "on deck" in readiness for message transfer. 
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[00049] The media integrator 206 may also include a UI transition engine 
210 to perform part of the exemplary method 800 by effecting a smooth transition 
of communications program UIs and by bringing unsent message content from the 
environment of a prior medium to the environment of a subsequent medium. In 
some implementations, a user is offered options to continue or stop the exemplary 
method 800 of transitioning to a subsequent presence-based communications 
medium. 
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CONCLUSION 

[00050] The subject matter described above can be implemented in hardware, 
in software, or in firmware, or in any combination of hardware, software, and 
firmware. In certain implementations, the subject matter may be described in the 
general context of computer-executable instructions, such as program modules, 
being executed by a computing device or communications device. Generally, 
program modules include routines, programs, objects, components, data structures, 
etc. that perform particular tasks or implement particular abstract data types. The 
subject matter can also be practiced in distributed communications environments 
where tasks are performed over wireless communication by remote processing 
devices that are linked through a communications network. In a wireless network, 
program modules may be located in both local and remote communications device 
storage media including memory storage devices. 

[00051] The foregoing discussion describes exemplary presence-based 
seamless messaging. Although the subject matter has been described in language 
specific to structural features and/or methodological acts, it is to be understood that 
the subject matter defined in the appended claims is not necessarily limited to the 
specific features or acts described above. Rather, the specific features and acts 
described above are disclosed as example forms of implementing the claims. 
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